This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
The Trusted Computing Group (TCG) is a group that develops and promotes the use of open, industry standard specifications for trusted computing building blocks and software interfaces across multiple platforms. TCG includes a number of different working groups, including the Mobile Phone Work Group, which is working on the adoption of TCG concepts while addressing specific features which are found in mobile devices.
A TCG Trusted Platform Module (TPM) allows an entity to create measurements of software. A measurement of software is referred to as an integrity metric. A sequence of measurements causes a sequence of these integrity metrics. A single integrity metric or a sequence of integrity metrics can be measured again into another integrity metric. This “measurement” of measurements can be used to determine whether the underlying software stack is valid/authorized or not based on a single metric. In a trusted platform, an operating system kernel uses a configuration file to check the integrity of a module prior to loading and executing. The configuration file includes a hash value (generated by Secure Hash Algorithm-1(SHA-1)) of the module to be loaded. The hash value is a mathematical value that is used to summarize the contents of the module. The hash value is recorded into one of a plurality of Platform Configuration Registers (PCRs) using a process called extension. This process keeps the size of the PCR constant and represents the sequence of recorded hashes using a single hash. The extension process ensures that the existing content in a PCR is not tampered with. For example, a PCR may contain a value of value1. The size of value1 (in terms of the number of bits) depends on the secure hash algorithm used. The extension process requires that changes to PCR are only performed by calculating the hash value (using a secure hash algorithm, for example SHA1) of the concatenation of the existing value of PCR and the hash value (using the same secure hash algorithm) of a new value. In other words, after the extension process, the PCR would contain SHA1(value1∥SHA1(“new value”)), assuming that the SHA1 hash function was used. The benefit of this extension process is that, when updating a PCR, it is not feasible to find a value x that, when used to extend a PCR with, would place the PCR in a state that would leave a reader to believe that ‘x’ would not have been extended or any of the previous extensions would not have been done. In other words, it is not feasible to erase the record of an extension operation or forge an extension operation.
One of the purposes of using trusted platforms is to ensure that untrusted hardware, software and/or software images have not been loaded onto a system. During a boot process, the system compares the values in the PCRs with precalculated values that are known to the system for each device or software. If the values match, then it is known that the device or software is trusted. If the values do not match, then the system knows that there is a trust issue and can take an appropriate action. For example, in the case of an operating system, non-matching values would indicate that a non-authorized operating system, or an unauthorized version of an operating system, is involved and should not be loaded.
Currently, there exists a dependency between two adjacent components in a sequence when their measurements are recorded to a PCR. Basing the authorization of a particular program component on the measurement of the previous component would require knowing the hash values of previously loaded components. Additionally, the update of a single component in the boot chain would require reauthorization of every component following it in the boot chain, with every other Reference Integrity Metric (RIM) certificate having to be updated.
As an example of the above, a boot sequence PCR (for example, PCR3) allocation is conventionally performed according to the PCR3=t(n)=SHA1(t(n−1)∥SHA1(“Boot-Event: DM load” name(Cn))). In this example, the name (Cn) denotes the name of the software component Cn, and t(n) denotes the value in PCR3 after the software component Cn is loaded, with t(0) being the initial value of PCR3. In this example, t(n) is dependent on t(n−1). Therefore, if a first component in the boot sequence changes, all remaining RIM certificates must be updated as well. This is not an efficient operation, requiring the use of resources which would otherwise be unnecessary.
In light of the above, it would be desirable to develop an improved system and method for verifying items during a secure boot process. Additionally, it would also be desirable to develop such an improved system that is also remotely manageable. “Remotely manageable” refers to the idea that the entity that is authenticated and authorizes which items are permitted to run on the system is not the local user. In a remotely manageable system, the remote, authorized party is capable of both authorizing items (such as operating system images) to run in the device and to revoke the permissions from previously authorized items. Entities which may be authorized to remotely manage the device include both device manufacturers and service providers.